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EFFICIENT PEER TO PEER DISCOVERY 

Field 



The invention pertains generally to networks. More 
5 particularly, the invention relates to a more efficient 

discovery method for peer-to-peer communications across 
different networks. 

Background 

In modern computer networks, computers (source computers) 

10 that seek to communicate with other computers (destination 

computers) , also known as peer-to-peer communications, should 
be able to determine the address of the destination computer. 

Q Typically, a source computer has the name of the destination 

computer but does not have the destination address (binding 

f§> information) necessary to communicate with the destination 

^ computer directly. 

5 There are a few types of name -to- address resolution 

I service models for networks supporting peer-to-peer 

M communications. One such name - t o - addre s s resolution scheme 

jjSp uses a server to maintain a list of all peer contact or 

M binding information (e.g., a name- to- address index), usually 

an Internet Protocol (IP) address. The disadvantage of this 
architecture is that it suffers from poor scalability and 
reliability. That is, as the network grows the list of peer 
25 addresses that is maintained becomes increasingly large. This 

inhibits efficient network communications. Because this 
approach relies on a server to maintain and provide peer 
addresses, this creates a large load on the server and exposes 
the network to a single point of failure. Additionally, 
30 delays in discovering new peers in the network is a source of 

unreliable communications. 
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One example of the server-centered name- to- address 
resolution service describe above is the World Wide Web (WWW) 
Domain Name Server (DNS) system. 

Another service model relies solely on communications 
between peers to resolve peer names and contact binding 
information. That is, broadcast messages and/or other types 
of notification schemes may be employed to inform peers about 
contact binding information for other peers. This model, 
typically referred to as pure peer-to-peer approach, has the 
disadvantage of increasing network traffic and being less 
reliable as network traffic increases. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a block diagram illustrating a network 
architecture with a typical peer address discovery scheme. 

Figure 2 is a block diagram illustrating one embodiment 
of the multi-network name -to- address resolution aspect of the 
invention. 

Figure 3 is a block diagram illustrating one embodiment 
of multi-network name-to-address resolution relationships 
according to one aspect of the invention. 

Figure 4 is a block diagram illustrating various multi- 
network name -to- address resolution relationships at different 
hierarchical levels according to one embodiment of the 
invention. 

Figure 5 is a flow diagram illustrating one method of 
sharing name- to- address resolution resources across multiple 
networks according to one embodiment of the invention. 
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DETAILED DESCRIPTION 



In the following detailed description of the invention, 
numerous specific details are set forth in order to provide a 
5 thorough understanding of the invention. However, the 

invention may be practiced without these specific details. In 
other instances well known methods, procedures, and/or 
components have not been described in detail so as not to 
unnecessarily obscure aspects of the invention. 
10 Throughout this description, the term 'address' generally 

refers to any contact or binding information necessary for a 
3 first peer to communicate with another peer. The term 'peer' 

Q generally refers to various devices including a processing 

tj device/unit, computer systems, and data storage devices. The 

f;5 term 1 server' generally refers to any computer or device which 

fy manages, maintains, and/or facilitates communications to 

4$ and/or from other computers. As employed in the description 

U and claims, the term 'name-to-address index' is used 

interchangeably to generally refer to any address resolution 
If resource that may be employed. Thus, the term 'index' should 

Q includes hash tables, look-up lists, and any other address 

resolution resource or method. 

In the accompanying figures, dashed lines are often used 
to indicate communications between devices and do not 
25 necessarily indicate a physical interface or coupling. Also, 

the label for each device (block) appears boxed or framed 
within the device. 

The invention provides a system, method, and device for 
quick and efficient peer-to-peer discovery (name-to-address 
30 resolution) across a mult i -network. 

Referring to Figure 1, one embodiment of a typical 
enterprise network is illustrated. An enterprise server (ES) 
serves as the host for name -to -address information for peers 
under it. In this illustration, the ES hosts the peer name- 
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to-address list/index for two networks, business unit #1 (BUI) 
network and business unit #2 (BU2) network. Each network 
comprises one or more peers (e.g., PI, P2 , P3 , P4 , and PN for 
the BUI network and XI, X2 , X3 , X4 , and XN for the BU2 network 
- where N denotes a positive integer) . Each of the business 
unit servers (e.g., BUI and BU2) typically maintains an index 
of local peer addresses. For example, BUI maintains a list of 
the peer addresses for the peers in its network (e.g. Pl-PN) . 
Similarly, business unit server BU2 maintains the peer 
addresses for the peers in its local network (e.g. Xl-XN) . 

Typically, a first peer that seeks to communicate with 
another peer in its network first obtains the address for the 
other peer. For example, in Figure 1 if PI wishes to 
communicate with P4 it first obtains its address from the 
business unit (BUI) server for the local network. Since BUI 
is the address server for the local network, it maintains the 
address for peer PI through PN, including P4 . Thus, BUI will 
be able to provide PI with the address for P4 . Upon receipt 
of the P4 address, PI will be able to communicate (send 
messages) with P4 . 

In one implementation, once a peer obtains the address 
information for another peer it stores it for future 
reference. Thus, a peer may maintain and index or list of one 
or more addresses. For example, PI maintains a list of other 
peer addresses including, P2 and P3 . Similarly, peer P2 
maintains the addresses for peers P3 and P4, peer P3 maintains 
the addresses for peers P4 and PI, peer P4 maintains the 
addresses for P2 and P3 , and PN maintains the address for PI. 

In one embodiment, a peer may save only the last n peer 
addresses of the peers with which it communicated, where n is 
a positive integer. Peers may also maintain other addresses 
such as the local business unit server (e.g. BU) and 
enterprise server (e.g. ES) to expedite network 
communications . 
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When a peer operating in a first network seeks to 
communicate with another peer operating in a second network it 
typically obtains the other peer's address from a server 
common to both networks . In a hierarchical network this means 
going up the hierarchy until a computer (server) is found 
which spans both networks. For example, when peer XN in the 
BU2 network seeks to communicate with peer PI in the BUI 
network, it first obtains its address. Peer XN first tries to 
obtain the address for PI from its local server BU2 . Since PI 
is in another network, BU2 is unable to provide the address, 
and the request fails. Peer XN then goes up one level to the 
enterprise server ES and request the address for PI. Since ES 
acts as the name server host for peer addresses in both the 
BUI and BU2 networks (it is common to both networks) , it 
maintains address information for peers in both networks, 
including PI. Thus, ES would respond to XN' s request with the 
address information for PI. 

The address discovery system described above and 
illustrated in Figure 1 has the disadvantage of relying on a 
single server ES to permit peer-to-peer communications across 
two networks (e.g. BUI network and BU2 network) . As noted 
above, reliance on a single server for inter-network 
communications causes traffic congestion and is susceptible to 
a single point of failure. 

One aspect of the invention provides a scheme to permit 
peer-to-peer communications between networks without reliance 
on a higher level server. A relationship is established 
between servers, each in different networks, to permit address 
information discovery or exchange (name-to-address resolution) 
for peers in one or both of the networks . 

Referring to Figure 2, a group of networks each managed 
by a business server (e.g. BUI, BU2 , and BU3) and all served 
by a single higher level server (e.g. ES) is illustrated. 
Like the network describe in Figure 1, if peer XN in network 



BU3 seeks to communicate with PI in network (BUI) , it contacts 
the common higher level server ES to obtain its address. 

According to one embodiment of the invention, a 
relationship is established between business unit servers BUI 
and BU2 such that a name -to- address resolution resources can 
be shared from one network to the other may be established 
without reliance on the higher level server (ES) . For 
example, if peer PI in the BUI network seeks to communicate 
with peer Al in the BU2 network it requests its address from 
its local server BUI as usual. Because a relationship has 
been established between servers BUI and BU2 (indicated by the 
direct bi-directional dashed line between the two servers) , 
server Bl is able to query server B2 to obtain the address for 
Al and return it to the requesting peer PI. Thus, PI is able 
to establish peer-to-peer communications without relying on 
the enterprise server ES for cross-network address resolution. 

Once a peer has obtained the address information for 
another peer, either within its local network or in another 
network, it may store such address for later reference. 

The address sharing relationship between two or more 
servers may be characterized as creating a 'common zone' 
across multiple networks. Common zones generally refer to 
logical groups of two or more networks which at some level 
share address resolution/discovery information without relying 
on higher level or common servers to do so. As used herein, 
common servers are servers which are at a higher level in the 
server hierarchy and span both of the networks . 

A common zone creates a transparent address discovery 
interface. From the perspective of a peer in a first network, 
peers on other networks appear to be x local' since there is no 
need to contact a higher level server to obtain its address. 

While the illustration in Figure 2 depicts a common zone 
for peers of networks BUI and BU2, common zone relationships 
are not limited to networks (or business units or servers) at 
the same hierarchical level. A common zone may be formed 
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between multiple networks at the same hierarchical level or 
networks at different hierarchical levels. For example, 
business server BUI may form a common zone relationship with a 
network operating under X3 (in network BU3) to share name-to- 
address information and expedite address resolution for peer- 
to-peer communications. Additionally, a local server (e.g. 
BUI) may establish multiple independent common zones with 
other servers . 

Another aspect of the invention enables access protection 
and restricted access to the peers on a given network. Unlike 
the typical DNS hierarchical architecture, where peer access 
may not be individually restricted to certain peers, common 
zone access according to the invention permits authorization- 
based access to peers across multiple networks. Only peers in 
the same common zone (e.g., BUI and BU2) are allowed to 
discover an address without having to query a higher level 
server common to both networks (e.g, ES) . In one 
implementation, relationships between local servers (or 
servers within a common zone) permit restricting access to 
authorized peers only. 

According to one implementation, a local server (e.g. 
BU2) may require a password or other authentication 
information before permitting an address discovery or sharing 
relationship to be established with another server (e.g. BUI) 
at the same hierarchical level. In other implementations, 
each server has a list of local servers with which it is 
allowed to share peer address information. A server may then 
check this list to determine if it may respond to an address 
information request from another server. 

Derivative or indirect address resolution via the common 
zone relationships may be permitted or restricted depending on 
the implementation. Derivative or indirect address resolution 
may occur where one server maintains two common zone 
relationships with two other servers. For example, as 
illustrated in Figure 3, server BU2 maintains a common zone 



relationship A with BUI and a common zone relationship B with 
BU3 . However, there is no direct common zone relationship 
between BUI and BU3 . Thus, BU2 may enable or prohibit common 
zone address discovery from BUI to BU3 depending on the 
application. 

In one implementation, server BU2 may deny an address 
request from a first peer in the BUI network (e.g. PI) for an 
address of a second peer in the BU3 network (e.g. XI) . In 
another implementation, server BU2 may provide the address 
information to a peer in the BUI network (e.g. PI) seeking to 
communicate with a peer in the BU3 network (e.g. XI) . 

Figure 4 illustrates yet another implementation of the 
invention where a common zone relationship is created across 
two enterprise networks. For example, a name-to-address 
sharing relationship may be created between ESI and ES2 such 
that shared peer address discovery may be implemented. For 
instance, a peer X5 within network BU4 may seek to communicate 
with a peer A4 within network ESI. First, X5 requests A4 ' s 
address from its local server BU4 . If such request fails 
because BU4 does not have access to A4's address, X5 requests 
the address from the next higher level server ES2 . Since ES2 
has an address sharing relationship (relationship A) with ESI, 
it is able to obtain the address and respond to the request. 
Moreover, the address sharing relationship between ESI and ES2 
does not prevent other direct address sharing relationships 
from being established. For example, a direct address sharing 
relationship (relationship B) may be established between BU2 
and BU3, each on different networks ESI and ES2 respectively. 
Thus, when peer Zl in network BU3 seeks to communicate with 
peer A4 in network BU2 , then server BU3 may directly query 
server BU2 to obtain A4 ' s address. 

Referring to Figure 5, according to one embodiment of the 
invention a server receives a request from a first peer for 
the binding information or address of a second peer 502. The 
server checks its local index to resolve the requested address 
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504. If the address is found 504, then the server returns the 
address to the first peer 508. If the address is not found 
504, then the server directly checks with servers for other 
networks within its common zones 510 to try to resolve the 
address request. If the second peer belongs to one of the 
other networks within the common zone, the address will be 
resolved and returned to the first peer 512 and 508. If the 
address is not found, then the server returns an address 
invalid or address not found message to the first peer 514. 

While certain exemplary embodiments have been described 
and shown in the accompanying drawings, it is to be understood 
that such embodiments are merely illustrative of and not 
restrictive on the broad invention, and that this invention 
should not be limited to the specific constructions and 
arrangements shown and described. Additionally, it is 
possible to implement the invention or some of its features in 
hardware, programmable devices, firmware, software or a 
combination thereof. The invention or parts of the invention 
may also be embodied in a processor readable storage medium or 
machine -readable medium such as a magnetic, optical, or 
semiconductor storage medium. 



